4.3 Beziehungen zwischen Objekten 

In Abbildung 4.10 haben wir bereits eine ganze Reihe von Beziehungen zwischen handelnden Personen der griechischen Mythologie dargestellt. Dabei haben Sie gesehen, dass Objekte in den unterschiedlichsten Beziehungen zueinander stehen können.

Wenn man in der objektorientierten Welt von Beziehungen spricht, unterscheidet man grundsätzlich drei Arten von Beziehungen:

Beziehungen zwischen Klassen und Objekten

Beziehungen zwischen Klassen und Objekten Eine solche Beziehung, die Klassifizierung, haben wir in Abschnitt 4.2.1 kennen gelernt. Die Klassifizierung beschreibt eine Beziehung zwischen einer Klasse und ihren Exemplaren. Das Objekt Plato steht zum Beispiel in so einer Beziehung mit der Klasse Mann, denn Plato ist ein Mann (oder auch ein Exemplar der Klasse Mann). In Abbildung 4.21 sehen Sie diese Beziehung an Markierung 2.

Beziehungen zwischen Klassen

Beziehungen zwischen Klassen untereinander Weil Plato ein Mann ist, und ein Mann eine Person, ist Plato sterblich, denn jede Person ist sterblich. Es besteht also eine Beziehung zwischen der Klasse der sterblichen Objekte und der Klasse Person – die Klasse Person ist eine Unterklasse der Klasse Sterblich. Und da jeder Mann eine Person ist, ist die Klasse Person eine Oberklasse der Klasse Mann. In Abbildung 4.21 wird dieser Zusammenhang an Markierung 1 dargestellt.

Beziehungen zwischen Objekten

Beziehungen zwischen Objekten untereinander Aristoteles hatte einen Lehrer, Plato, und einen bekannten Schüler, Alexander den Großen. Dies sind Beispiele einer Beziehung zwischen konkreten Objekten, denen wir uns jetzt widmen werden. In Abbildung 4.21 sehen Sie diese Beziehungen an den Markierungen 3 und 4.

Hier klicken, um das Bild zu vergrößern

Assoziation, Aggregation und Komposition

Beziehungen zwischen verschiedenen Objekten werden ganz allgemein auch Assoziation genannt.¹  Außerdem gibt es spezielle Formen von Assoziationen.

Beziehungen zwischen einem Objekt und seinen Teilen werden Aggregation beziehungsweise Komposition genannt. Die Unterscheidung zwischen Aggregation und Komposition ist recht subtil und hängt häufig nur von der Betrachtungsweise des Entwicklers ab. Wir werden uns der Aggregation und der Komposition in Abschnitt 4.3.8 näher widmen.

Assoziationen zwischen Objekten

Schauen wir uns im Folgenden an, was wir über die Assoziationen zwischen Objekten sagen können.

Eine Assoziation hat immer eine semantische Bedeutung. Zwei oder mehrere Objekte können zueinander in verschiedenen Beziehungen stehen. So wie im Leben zwei Menschen in der Beziehung Elternteil – Kind und unabhängig davon in der Beziehung Lieferant – Kunde zueinander stehen können.² 

4.3.1 Rollen und Richtung einer Assoziation 

Die Beziehungen zwischen Objekten sind meistens nicht symmetrisch, das heißt, dass jedes Objekt eine unterschiedliche Rolle in der Beziehung einnimmt. Wir können sagen, dass Zeus auf dem Olymp wohnt, nicht aber der Olymp auf dem Zeus. Die Bezeichnung einer Beziehung hat also eine Richtung.

Hier klicken, um das Bild zu vergrößern

4.3.2 Navigierbarkeit 

Eine weitere wichtige Eigenschaft einer Beziehung ist ihre Navigierbarkeit. Nehmen wir an, es besteht eine Assoziation schickt Werbung zwischen den Exemplaren der Klasse Firma und der Klasse Person. Die Firma kann alle Personen auflisten, denen sie Werbung zuschickt. Eine Person hat aber keine Liste der Firmen, die sie mit Werbung belästigen. Wir sagen, dass die Assoziation schickt Werbung in der Richtung Firma-Person navigierbar ist, nicht jedoch in der Richtung Person-Firma. Die Navigierbarkeit wird meistens in den Designmodellen angegeben, in den Analysemodellen spielt die Navigierbarkeit selten eine Rolle.

Hier klicken, um das Bild zu vergrößern

4.3.3 Kardinalität 

Die Kardinalität einer Beziehung sagt aus, wie viele Objekte des jeweiligen Typs in dieser Beziehung stehen können.

Dateien im Dateisystem

Nehmen wir zum Beispiel ein Modell für ein einfaches Dateisystem, in dem jede Datei immer in genau einem Verzeichnis liegt. Ein Verzeichnis kann aber leer sein, oder es kann eine oder mehrere Dateien enthalten. Die mögliche beziehungsweise nötige Anzahl der Objekte, mit denen ein Objekt in einer Beziehung stehen kann, bezeichnen wir als die Kardinalität oder auch die Multiplizität dieser Beziehung.³ 

Ein beliebtes Beispiel für eine Beziehung zwischen Objekten ist die Beziehung Elternteil-Kind. Die Kardinalität der Rolle Kind ist beliebig viele, denn es gibt Menschen, die keine Kinder haben, und Menschen, die ein oder mehrere Kinder haben. Wie sieht es aber mit der Kardinalität der Rolle Elternteil aus? Wenn wir zum Beispiel eine genealogische Anwendung schreiben, würde man spontan sagen, dass sie 2 ist, denn jeder Mensch hat genau eine biologische Mutter und genau einen biologischen Vater. Dennoch könnten wir diese Beziehung in unserer Anwendung nicht so modellieren.⁴ 

Mögliche Kardinalitäten

Am häufigsten treffen wir auf Beziehungen mit folgenden Kardinalitäten:

Ein Objekt steht in einer Beziehung mit

genau einem anderen Objekt.

keinem oder einem anderen Objekt.

mindestens einem anderen Objekt.

beliebig vielen anderen Objekten.

Es kann aber durchaus Beziehungen mit anderen Kardinalitäten geben. Zum Beispiel in der Beziehung Tennismatch-Spieler ist die Kardinalität der Spieler zwei oder vier.

In Abbildung 4.24 wird das Konzept der Kardinalität in UML verdeutlicht. An Markierung 1 ist eine Assoziation zwischen Exemplaren derselben Klasse Person dargestellt. Die Assoziation wird durch eine Linie repräsentiert, die am Kästchen Person anfängt und endet, denn sowohl die Rolle Kind als auch die Rolle Elternteil wird von Personen gespielt. Ein und dieselbe Person kann in dieser Beziehung für andere Personen der Elternteil und für andere das Kind sein. Diese Person kann (nach diesem Modell) beliebig viele Kinder, aber maximal zwei Eltern haben.

Hier klicken, um das Bild zu vergrößern

Mehrwertige Beziehungen

Wenn die maximale Kardinalität einer Beziehung größer als 1 ist (z. B. »*«), die Beziehung also mehrwertig ist, können wir uns Gedanken über die Struktur der Objekte am mehrwertigen Ende der Beziehung machen. Wenn die Objekte in dieser Beziehung eine definierte Reihenfolge haben, sagt man, dass die Beziehung geordnet ist.

Eine weitere Frage, die wir uns stellen können, ist die Frage, ob ein Objekt in der Beziehung mehrfach aufgelistet sein kann. Ein Team kann aus mehreren Spielern bestehen, ein konkreter Spieler kann aber nicht mehrfach in einem Team auftauchen. Eine Reiseroute kann durch mehrere Städte führen, dabei kann eine Stadt in einer Route mehrfach durchlaufen werden.

Mehrwertige Beziehungen als Menge

Wenn nichts Abweichendes angegeben ist, verstehen wir eine mehrwertige Beziehung üblicherweise als eine Menge (englisch Set) ohne definierte Ordnung, in der ein Objekt nur einmal auftreten kann. Ist die Reihenfolge definiert, gilt für die Beziehung die Einschränkung {ordered} oder {ordered set}, je nachdem, ob ein Objekt mehrfach auftreten kann. Es gibt auch den Fall, in dem ein Objekt zwar mehrfach auftreten kann, die Ordnung aber trotzdem keine Rolle spielt. Diese Art der Beziehung wird im Englischen als Bag, im Deutschen als »Korb« bezeichnet. Ein Beispiel einer solchen Beziehung wäre die Liste der Abonnenten einer Zeitschrift, wenn der Verlag kein Aussortieren von Dubletten vorgenommen hat. Ein Kunde kann eine Zeitschrift mehrfach abonniert haben, die Reihenfolge, in der die Zeitschrift versendet wird, spielt aber keine Rolle.

Hier klicken, um das Bild zu vergrößern

4.3.4 Qualifikatoren 

Manchmal kann man über die Kardinalität einer Beziehung eine genauere Aussage treffen. Zum Beispiel kann ein Mensch im Laufe seines Lebens mehrere Ehepartner haben. Doch zu einem Zeitpunkt, zumindest in unserem Kulturkreis, kann ein Mensch höchstens einen Ehepartner haben. Ein anderes Beispiel ist die Beziehung zwischen einer Firma und ihren Kunden. Eine Firma kann viele Kunden haben, aber durch eine Kundennummer kann sie einen ihrer Kunden eindeutig identifizieren. Pro Kundennummer hat eine Firma also genau einen Kunden.

Diese Informationen über die Kardinalität einer mehrwertigen Beziehung können wir durch die Angabe der Qualifikatoren ausdrücken. Mithilfe eines Qualifikators kann man aus vielen Objekten an einem mehrwertigen Ende einer Beziehung bestimmte Objekte auswählen.

Hier klicken, um das Bild zu vergrößern

In der Beziehung Ehe ist zum Beispiel ein Zeitpunkt ein Qualifikator, der es uns ermöglicht, einen konkreten Ehepartner eines mehrmals verheirateten Menschen genau zu bestimmen. Die Kundennummer ist wiederum ein solcher Qualifikator in der Beziehung zwischen einer Firma und seinen Kunden.

4.3.5 Beziehungsklassen, Attribute einer Beziehung 

Schauen wir uns jetzt die Beziehung Job zwischen den Klassen Person und Firma an.

Hier klicken, um das Bild zu vergrößern

Es gibt Personen ohne Job, eine Person kann aber auch mehrere Jobs haben. Eine Firma hat (zumindest in unserem Modell) immer mindestens einen Beschäftigten, sei es der Unternehmer selbst. Die Kardinalität der Rolle Arbeitgeber ist also 0..*, die der Rolle Arbeitnehmer 1..*.

Obwohl die Reihenfolge der Mitarbeiter keine Rolle spielt und wir deswegen die Beziehung in Richtung Firma-Person als eine Menge (Set) modelliert haben, ist es doch wichtig zu wissen, welche Funktion ein Mitarbeiter in einer Firma hat. Und wichtig ist auch, zumindest für die meisten von uns, die in einer solchen Beziehung stehen, wie hoch das Gehalt⁵  eines Menschen in einer Firma ist.

Welcher Klasse können wir diese Informationen zuordnen? Offensichtlich können wir die Attribute Funktion und Gehalt nicht der Klasse Firma zuordnen, denn dann müssten alle Mitarbeiter die gleiche Funktion haben und dasselbe Gehalt verdienen.

Würden wir diese Attribute der Klasse Person zuordnen, könnte zwar jeder Mitarbeiter eine eigene Funktion und sein eigenes Gehalt haben, allerdings müssten die Funktion und sein Gehalt bei jeder Firma gleich sein. Außerdem hätten diese Attribute bei einem Menschen ohne Job keine Bedeutung.⁶ 

Assoziationsklasse

Die Lösung unserer Aufgabe ist, die Attribute weder der Klasse Firma noch der Klasse Person zuzuordnen, sondern der Beziehung Job selbst. In diesem Falle spricht man von einer Assoziationsklasse oder auch einer Beziehungsklasse.

Hier klicken, um das Bild zu vergrößern

4.3.6 Implementierung von Beziehungen 

Beziehungen unterscheiden sich unter anderem durch ihre Kardinalität, ihre Navigierbarkeit; die mehrwertigen können geordnet oder ungeordnet sein; ein Objekt kann einmal oder mehrfach auftreten. Es gibt also sehr viele Varianten von Beziehungen. Aus diesem Grunde findet man in den gängigen Programmiersprachen keine speziellen Konstrukte für die Umsetzung der Beziehungen.

Umsetzung von Beziehungen

Stattdessen verwendet man bei einwertigen Beziehungen in dem Objekt, von dem die Beziehung navigierbar ist, meistens Zeiger oder Referenzen, die zu dem anderen Objekt zeigen.

Eine beidseitig navigierbare Beziehung wird am häufigsten implementiert durch zwei Zeiger oder Referenzen, die programmtechnisch synchron gehalten werden müssen.

Die mehrwertigen Beziehungen werden auf verschiedene Arten umgesetzt. Verwendet werden Arrays, Listen, Mengen oder andere Containerkonstrukte, die in der jeweiligen Programmiersprache vorhanden sind oder die man selbst implementiert.

Beziehungsklassen werden als gewöhnliche Klassen implementiert.

Listing 4.12 stellt die Umsetzung von verschiedenen Beziehungen in Java dar. Wir zeigen dabei eine mögliche Umsetzung einer beidseitig navigierbaren Mengenbeziehung Person–Adresse. Eine Person kann mehrere Adressen haben, und unter einer Adresse kann man mehrere Personen finden.

class Person {
        private Set<Address> addresses = new HashSet<Address>();
        // Hier verwalten wir eine Richtung der Beziehung
        // Person-Address:
        public void addAddress(Address address) {
          if (addresses.contains(address)) return;
          adresses.add(address);
          address.addPerson(this); // die andere Richtung pflegen
        }
        ...
      }
      
      class Address {
      private Set<Person> people = new HashSet<Person>();
        // Hier verwalten wir eine Richtung der Beziehung
        // Person-Address:
        public void addPerson(Person person) {
          if (people.contains(person)) return;
          people.add(person);
          person.addAddress(this); // die andere Richtung pflegen
        }
        ...
      }

Listing 4.12   Abbildung von Beziehungen auf Klassen

4.3.7 Komposition und Aggregation 

Bisher haben wir uns die Beziehungen zwischen verschiedenen Objekten angeschaut. Doch ein Objekt selbst kann eine komplexe Struktur besitzen, und wir können die Beziehungen zwischen dem Objekt und seinen Teilen modellieren. Dabei unterscheiden wir zwischen Komposition und Aggregation.

Sowohl die Komposition als auch die Aggregation sind Teil-von- bzw. Besteht-aus-Beziehungen. Wir können zum Beispiel modellieren, dass eine Bestellung aus den Bestellungsposten oder dass eine Fußballmannschaft aus ihren Spielern besteht.

Unterschied Aggregation–Komposition

Eine Aggregation unterscheidet sich von einer Komposition

in der Anzahl der zusammengesetzten Objekte, deren Teil ein Objekt sein kann, und

in der Lebensdauer der zusammengesetzten Objekte und deren Teile.

Ein Beispiel für eine Aggregation ist die Beziehung zwischen einer Mannschaft und ihren Spielern. Ein Mensch kann in mehreren Mannschaften spielen, und wird eine Mannschaft aufgelöst, bedeutet es in den allermeisten Fällen nicht das Ende für ihre Ex-Spieler.

Ein Beispiel für eine Komposition ist die Beziehung zwischen einer Bestellung und den einzelnen Posten der Bestellung. Ein Bestellungsposten gehört in genau eine Bestellung, und wird die Bestellung gelöscht, löscht man automatisch auch alle ihre Posten.

Hier klicken, um das Bild zu vergrößern

Alternativ kann man die Komposition auch darstellen wie in Abbildung 4.30 gezeigt.

Hier klicken, um das Bild zu vergrößern

Einsatz von Komposition und Aggregation

Die Entscheidung, ob wir eine Beziehung als eine Aggregation, eine Komposition oder als einfache Assoziation modellieren sollten, ist oft schwierig, weil es keine festen Regeln gibt, nach denen wir unterscheiden können, welche der Möglichkeiten die geeignete ist. Die semantische Bedeutung ist in UML nur vage definiert, man spricht von einem Modellierungsplacebo. Wie wir aber wissen, Placebos wirken. Versuchen wir also ein paar Richtlinien aufzustellen, die uns bei der Entscheidung helfen, welche Variante wir einsetzen sollen.

Hierarchie

Durch die Verwendung der Komposition lässt sich sehr gut ausdrücken, dass eine Beziehung zwischen den Objekten derselben Klasse hierarchisch ist. Gute Beispiele hierfür sind Organigramme oder Dateisysteme.

Lebensdauer und Persistenz

Eine andere Information, die sich durch die Modellierung einer Komposition ausdrücken lässt, ist das Verhalten der Objekte beim Löschen oder beim Speichern des Kompositums. Da das Kompositum aus Teilen besteht, die nur als Teile des Kompositums existieren, werden sie mit dem Kompositum gelöscht beziehungsweise gespeichert. Diese Semantik betrifft jedoch die dynamischen Aspekte der Modelle, und die Klassendiagramme sind für die Darstellung der statischen Sachverhalte vorgesehen.

Datenstruktur

Eine sinnvolle Verwendung einer Komposition ist die Modellierung der Klassen in C++. Dort wird die Struktur des Speichers, in dem die Daten eines Objekts gehalten werden, explizit ausprogrammiert. Ob ein Objekt seine Teile direkt enthält oder ob es Zeiger auf andere Speicherbereiche enthält, ist eine Tatsache, die man hervorragend mit der Verwendung der Komposition ausdrücken kann. Dies ist jedoch keine allgemeine Vorgabe von UML, es ist nur ein Vorschlag, dem man bei der grafischen Darstellung der C++-Klassen in einem UML-Klassendiagramm folgen kann.

Diskussion: Komposition und Aggregation

Bernhard: Wie entscheide ich denn nun konkret, ob ich eine Beziehung als Komposition, Aggregation oder einfach als Assoziation modelliere?

Gregor: Einige Hinweise haben wir ja schon gegeben. Vor allem das technische Kriterium, ob die referenzierten Bestandteile mit einem anderen Objekt zusammen gelöscht werden sollen, deutet stark auf eine Komposition hin.

Bernhard: Und wenn sich das zur Zeit der Modellierung gar nicht so genau entscheiden lässt?

Gregor: Bedacht angewandt können die Komposition und die Aggregation zum besseren Verständnis des Modells beitragen. Manchmal ist es einfach natürlich zu sagen, dass ein Objekt aus anderen Objekten besteht. Wir sollten aber nicht zu viele Gedanken und zu viel Zeit an die Modellierungsentscheidung verschwenden. Jede Komposition und jede Aggregation lässt sich nämlich auch einfach durch eine Assoziation mit entsprechenden Einschränkungen und der Angabe der Navigierbarkeit und der Kardinalität abbilden.

4.3.8 Attribute 

Neben seiner Funktionalität und den Beziehungen zu anderen Objekten hat ein Objekt Attribute – Eigenschaften, die das Objekt beschreiben, und Daten, die das Objekt verwaltet. In Abschnitt 4.1.1 haben wir bereits vorgestellt, wie Eigenschaften von Objekten beschrieben werden.

Genau genommen entsprechen Attribute eines Objekts den Komponenten dieses Objekts in verschiedenen Kompositionsbeziehungen. Das Attribut-Sein und das Komponente-Sein sind zwei austauschbare Beschreibungsmöglichkeiten desselben Konzeptes. Daher entspricht die Notation für die Darstellung der Attribute in UML der kompakten Notation für die Darstellung der Komposition.

Für Attribute gilt also das Gleiche wie für die Komposition: Sie können ein- oder mehrwertig sein. Wenn sie mehrwertig sind, kann die Reihenfolge der Werte relevant oder irrelevant sein. Ein Wert kann mehrfach vorkommen, oder jeder Wert muss eindeutig sein.

Die Kardinalität des Ganzen ist bei Attributen genau wie bei der Komposition genau 1. Die Navigierbarkeit hat bei den Attributen fast immer die Richtung Zusammengesetztes Objekt-Attribut. Sollte irgendwann eine andere Art der Navigierbarkeit benötigt werden, empfehlen wir, diese Beziehung nicht als Attribut, sondern als Komposition zu modellieren.

4.3.9 Beziehungen zwischen Objekten in der Übersicht 

In Abbildung 4.31 sehen Sie noch einmal die UML-Darstellungsmöglichkeiten für Beziehungen zwischen Objekten in der Übersicht.

Hier klicken, um das Bild zu vergrößern

¹  Obwohl in UML eine Assoziation als eine Linie zwischen den Klassenkästchen dargestellt wird, ist eine Assoziation eine Beziehung zwischen Objekten – den Exemplaren dieser Klassen. Ein Beispiel einer Beziehung zwischen Klassen wäre die Generalisierung, der wir uns in Abschnitt 5.1.1, Hierarchien von Klassen und Unterklassen, widmen werden.

²  Wir werden uns in diesem Buch nicht allen Details der Fähigkeiten der UML widmen, eine tiefer gehende Beschreibung können Sie in [Kecher2005] finden.

³  Obwohl der Begriff Multiplizität unserer Ansicht nach besser ausdrückt, welche Eigenschaft von Beziehungen hier gemeint ist, verwenden wir in der Folge doch den Begriff Kardinalität. Zum einen ist dieser Begriff gebräuchlicher. Zum anderen haben wir uns auch nach dem Versuch, Multiplizität dreimal hintereinander schnell auszusprechen, gegen die Verwendung dieses Begriffs entschieden.

⁴  Warum können wir die Kardinalität der Rolle »Elternteil« nicht als 2, sondern nur als 0..2 implementieren? Diese Frage ist eine kleine Denkaufgabe für Sie, geehrter Leser!

⁵  Wir meinen hier sowohl die Löhne als auch die Gehälter.

⁶  Würden wir ein Personalverwaltungssystem für einen Arbeitgeber entwickeln, könnten wir durchaus die Attribute Funktion und Gehalt der Klasse Mitarbeiter zuordnen. Ein Mensch kann zwar mehrere Jobs haben, für unser System wäre dies aber nicht relevant. Die Jobs, die ein Mitarbeiter bei anderen Firmen hat, würden wir nicht verwalten.